std: Revert addition of into_ascii_* methods
#32314
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The addition of these methods in rust-lang#31335 required adding impls of the trait for the `String` and `Vec<T>` types. This unfortunately caused a regression (rust-lang#32074) in type inference for using these methods which the libs team has decided to not push forward with. These methods were stabilized in rust-lang#32020 which was intended to get backported to beta, but the backport hasn't happened just yet. This commit reverts both the addition and stabilization of these methods. One proposed method of handling this, in rust-lang#32076, was to move the methods to an extra trait to avoid conflicts with type inference. After some discussion, however, the libs team concluded that we probably want to reevaluate what we're doing here, so discussion will continue on the tracking issue, rust-lang#27809.
|
r? @brson (rust_highfive has picked a reviewer for you, use r? to override) |
|
Nominating for beta inclusion as well to fix the inference regression caused by using the stable methods. |
alexcrichton
added
beta-nominated
|
r? @aturon |
|
Can you run crater on this change? I see some hits on github code search... |
|
Crater reports one regression which seems to be spurious? |
|
@bors: r+ |
|
📌 Commit af65d81 has been approved by |
|
@alexcrichton Would it make sense to have a regression test for #32074? |
bors
added a commit
that referenced
this pull request
Mar 19, 2016
std: Revert addition of `into_ascii_*` methods The addition of these methods in #31335 required adding impls of the trait for the `String` and `Vec<T>` types. This unfortunately caused a regression (#32074) in type inference for using these methods which the libs team has decided to not push forward with. These methods were stabilized in #32020 which was intended to get backported to beta, but the backport hasn't happened just yet. This commit reverts both the addition and stabilization of these methods. One proposed method of handling this, in #32076, was to move the methods to an extra trait to avoid conflicts with type inference. After some discussion, however, the libs team concluded that we probably want to reevaluate what we're doing here, so discussion will continue on the tracking issue, #27809. Closes #32074
|
@eddyb good point, I'll add that if this bounces or in another PR if it lands |
alexcrichton
added
the
beta-accepted
alexcrichton
removed
the
beta-nominated
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The addition of these methods in #31335 required adding impls of the trait for
the
StringandVec<T>types. This unfortunately caused a regression (#32074)in type inference for using these methods which the libs team has decided to not
push forward with. These methods were stabilized in #32020 which was intended to
get backported to beta, but the backport hasn't happened just yet. This commit
reverts both the addition and stabilization of these methods.
One proposed method of handling this, in #32076, was to move the methods to an
extra trait to avoid conflicts with type inference. After some discussion,
however, the libs team concluded that we probably want to reevaluate what we're
doing here, so discussion will continue on the tracking issue, #27809.
Closes #32074